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PROPOSED REMOTE JOB ENTRY PROTOCOL 


Remote job entry is the mechanism whereby a user at one location 
causes a batch-processing job to be run at some other location. This 
protocol specifies the Network standard procedures for such a user to 
communicate over the Network with a remote batch-processing server, 
causing that server to retrieve a job-input file, process the job, 
and deliver the job’s output file(s) to a remote location. The 
protocol uses TELNET (to a special standardized logger, not socket 1) 
connection for all control communication between the user and the 


server RJE process. The server-site then uses the File Transfer 
Protocol to retrieve the job-input file and to deliver the output 
file(s). 


There are two types of users: direct users (persons) and user 
processes. The direct user communicates from an interactive terminal 
attached to a TIP or any host. This user may cause the input and/or 
output to be retrieved/sent on a specific socket at the specified 
host (such as for card readers or printers on a TIP), or the user may 
have the files transferred by pathname using File Transfer Protocol. 
The other type of user is an RJE User-process in one remote host 
communicating with the RJE Server-process in another host. This type 
of user ultimately receives its instructions from a human user, but 
through some unspecified indirect means. The command and response 
streams of this protocol are designed to be readily used and 
interpreted by both the human user and the user process. 


A particular user location may choose to establish the TELNET control 
connection for each logical job or may leave the control connection 
open for extended periods. If the control connection is left open, 
then multiple job-files may be directed to be retrieved or optionally 
(to servers that are able to determine the end of one logical job by 
the input stream and form several jobs out of one input file) one 


continuous retrieval may be done (as from a TIP card reader). This 
then forms a "hot" card reader to a particular server with the TELNET 
connection serving as a "job monitor". Since the output is always 


transferred job at a time per connection to the output socket, the 
output from this "hot" reader would appear when ready as if toa 
"hot" printer. Another possibility for more complex hosts is to 
attach an RJE User-process to a card reader and take instructions 
from a lead control card, causing an RJE control TELNET to be opened 
to the appropriate host with appropriate logon and input retrieval 
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commands. This card reader would appear to the human user as a 
Network "host" card reader. The details of this RJE User-process are 
beyond the scope of this protocol. 


GENERAL SPECIFICATIONS 


Ts User - A human user at a real terminal or a process that 
supplies the command control stream causing a job to be 
submitted remotely will be termed the User. The procedure by 
which a process user receives its instructions is beyond the 
scope of this protocol. 


2x User TELNET - The User communicates its commands over the 
Network in Network Virtual Terminal code through a User TELNET 
process in the User’s Host. This User TELNET process initiates 
its activity via ICP to the standard "RJE logger" socket (socket 
5) at the desired RJE-server Host. 


Bi RJE-server TELNET - The RJE-server process receives its command 
stream from and sends its response stream to the TELNET channel 
through an RJE-server TELNET process in the server host. This 
process must listen for the ICP on the "RJE logger" socket (and 
cause appropriate ICP socket shifting). 


4. TELNET Connection - The command and response streams for the RJE 
mechanism are via a TELNET-like connection to a special socket 
with full specifications according to the current NWG TELNET 


protocol. 
Sa RJE-Server - The RJE-Server process resides in the Host which is 
providing Remote Batch Job Entry service. This process receives 


input from the RJE-Server TELNET, controls access through the 
"logon" procedure, retrieves input job files, queues jobs for 
execution by the batch system, responds to status inquiries, and 
transmits job output files when available. 


6. User FTP - All input and output files are transferred under 
control of the RJE-server process at its initiative. Those 
files may be directly transferred via Request-for-connection to 
a specific Host/socket or they may be transferred via File 
Transfer Protocol. If the later method is used, then the RJE- 
server acts through its local User FTP process to cause the 
transfer. This process initiates activity by an active 
Request-—for-connection to the "FTP Logger" in the foreign host. 
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Server FTP - This process in a remote host (remote from the 
RJE-server) listens for an ICP from the User FTP and then acts 
upon the commands from the User FTP causing the appropriate file 
transfer. 


FTP - When File Transfer Protocol is used for RJE files, the 
standard FTP mechanism is used as fully specified by the current 
NWG FTProtocol. 


RJE Command Language - The RJE system is controlled by a command 
stream from the User over the TELNET connection specifying the 
user’s identity (logon), the source of the job input file, the 
status, altering job status or output disposition. Additional 
commands affecting output disposition are includable in the job 
input file. This command language is explicitly specified ina 
following section of this protocol. 


RJE Command Replies - Every command input from the User via 
TELNET and certain other conditions calls for a response message 
from the RJE-server to the User over the TELNET connection. 
These messages are formatted in a standardized manner to 
facilitate interpretation by both human Users and User 
processes. A following section of this protocol specifies the 
response messages. 


RJE COMMANDS OVER TELNET CONNECTION 


GENERAL CONVENTIONS 


Holland 


All commands will be contained in one input line terminated by 


the standard TELNET "crlf". The line may be of any length 
desired by the user (explicitly, not restricted to a physical 
terminal line width). The characters "cr" and "1f" will be 


ignored by the RJE-server except in the explicit order "crlf" 
and may be used as needed for local terminal control. 


All commands will begin with a recognized command name and may 
then contain recognized syntactic element strings and free-form 
variable strings (for userid, pathnames, etc.). Recognized 
words consist of alphanumeric strings (letters and digits) or 
punctuation. Recognized alphanumeric string elements must be 
separated from each other and from unrecognizable strings by at 
least one blank or a syntactically permitted punctuation. Other 
blanks may be used freely as desired before or after any 
syntactic element. The "=" after the command name in all 
commands except OUT and CHANGE are optional. 
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3. Recognized alphanumeric strings may contain upper case letters 
or lower case letters in any mixture without syntactic 
differentiation. Unrecognizable strings will be used exactly as 
presented with full differentiation of upper and lower case 
input, unless the host finally using the string defines 
otherwise. 


4. There are two types of Unrecognizable strings: final and 
imbedded. Final strings appear as the last syntactic element of 
a command and are parsed as beginning with the next non-blank 
character of the input stream and continuing to the last non- 
blank character before the "crlf". 


Imbedded strings include "job-id" and "Jjob-file-id" in the OUT, 
CHANGE, and ALTER commands. At present these fields will be 
left undelimitted since they must only be recognizable by the 
server host which hopefully can recognize its own job-ids and 
file-names. 


SYNTAX: The following command descriptions are given in a BNF-like 
syntax. Parenthesized names are non-terminal syntactic elements 
which are expanded in succeeding syntactic equations. Each 
equation has the defined name on the left of the ::= and a set 
of alternative definitions, separated by slashes "/", on the 
right. The equations for (host-file) and (disp) use the 
characters "/" "( )" explicitly in their definitions. In these 
cases the quotes are not part of the definition, but surround 
literal text which is part. 


USER 
USER = (user-id) 
This command must be the first command over a new TELNET 


connection. As such, it initiates a "logon" sequence. The 
response to this command is either 


a) User code in error. 
b) Enter password (if usercode ok) 
c) Log-on ok, proceed. (if no password required) 


Another USER command may be sent by the User at any time to change 
Users. Further input will then be charged to the new user. A 
server may refuse to honor a new user command if it is not able to 
process it in its current stat (during input file transfer, for 
example), but the protocol permits the USER command at any time 
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without altering previous activity. An incorrect subsequent USER 
command or its following PASS command are to be ignored with error 
response, leaving the original User logged-in. 


It is permissable for a server to close the TELNET connection if 
the initial USER/PASS commands are not completed within a server 
specified time period. 


It is not required or implied that the "logged-on" User be the 
user-id used for file transfer or job execution, but only 
identifies the submitter of the command stream. Servers will 
establish their own rules relating User-id with the job-execution- 
user for Job or Output alteration commands. 


Successful "log-on" always clears any previous Input or Output 
default parameters (INID, etc.). 


PASS 
PASS = (password) 


This command immediately follows a USER command and completes the 
"log-on" procedure. Although a particular Server may not require 
a password and has already indicated "log-on ok" after the USER 
command, every Server must permit a PASS command (and possibly 
ignore it) and acknowledge it with a "log-on ok" if the log-on is 
completed. 


BYE 
BYE 


This command terminates a USER and if input transfer is not in 
progress, closes the TELNET connection. If input is in progress, 
the connection will remain open for result response and will then 
close. During the interim, a new USER command (and no other 
command) is acceptable. 


An unexpected close on the TELNET connection will cause the server 
to take the effective action of an ABORT and BYE. 


INID/INPASS 
INID = (user-id) 
INPASS = (password) 
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The specified Userid and Password will be sent in the File 
Transfer request to retrieve the input file. These parameters are 
not used by the Server in any other way. If this command does not 
appear, then the USER/PASS parameters are used. 


INPATH/INPUT 
INPATH = (pathname) 
INPUT = (pathname) 
INPUT 


NOTE: The following syntax will also be used for output 
(pathname). 


(pathname) ::= (host-socket) / (host-file) 
(host-socket)::= (host), (socket) / (socket) 
no (host) part implies the User-site host 
(host)::= (decimal-integer) / (standard-host-name) 
(socket)::= (decimal-integer) / PORT (decimal-integer) 
(decimal-integer) implies explicit socket, lower bit 
will be set appropriately for the direction 
PORT implies the specified port-sockets for a TIP 
Tip-Socket = Port * 2**16 + (2 or 3) 


(host-file)::= (host) (attributes)"/"(file-name) 
(attributes)::= (empty) / : (transmission) (code) 
(transmission)::= (empty) /T/A/N 


(empty) implies default which is 
N for Input files 
A for output files 
T specifies TELNET-like coding with imbedded "crlf" 
for new-line, "ff" for new-page 
N specifies FTP blocked transfer with record marks 
but without other carriage-control 
A specifies FTP blocked records with ASA carriage- 
control (column 1 of image is forms control) 
(code)::= (empty) / E 
(empty) specifies NVT ASCII code 
E specifies EBCDIC (TE not allowed) 
(file-name)::= (any string recognized by the 
FTP Server at the site of the file) 


The (pathname) syntax is the general RJE mechanism for specifying a 
particular file source or destination for input or output. If the 
(host-socket) form is used then direct transfer will be made by the 
RJE-Server to the named socket using TELNET-like ASCII. If the 
(host-file) form is used then the RJE-server will call upon its local 
FTP-user process to do the actual transfer. The data stream in this 
mode is either TELNET-like ASCII or blocked records (which may use 
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column 1 for ASA carriage-control). Although A mode is permitted on 
input (column 1 is deleted) the usual mode would be the default N. 
The output default A would supply carriage-control in the first 
character of each record ("blank"= single-space, "1"=new-page, etc.), 
while the optional N mode would transfer the data only (as to a card 
punch, etc.). 


The (file-name) is an arbitrary Unrecognized string which is saved by 
RJE-server and sent back over FTP to the FTP-server to retrieve or 
store the appropriate files. 


INPATH or INPUT commands first store the specified (pathname) if one 
is supplied, and then the INPUT command initiates input. The INPATH 
name may be used to specify a pathname for later input and the INPUT 
command without pathname will cause input to initiate over a 
previously specified pathname. An INPUT "crlf" command with no 
previous (pathname) specified is illegal. 


ABORT 
ABORT 


This command aborts any input retrieval in progress, discards 
already received records, and closes the retrieval connection. 


Note: ABORT with parameters is an Output Transmission control. 
OUTUSER/OUTPASS 

OUTUSER = (user-id) OUTPASS = (password) 

The specified Userid and Password will be sent in the File 

Transfer request to send the output file(s). These parameters are 


not used by the Server in any other way. If this command does not 
appear, then the USER/PASS parameters are used. 
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OUT 
OUT (out-file) = (disp) (pathname) 


(out-file)::= (empty) / (job-file-id) 

(empty) implies the primary print file of the job 
(job-file-id)::= (string representing a specific output file 

from the job as recognized by the Server) 

(disp) ::= (empty) / "(H)" / "(s)" / "(D)" 

(empty) specifies Transmit then discard 

(H) specifies Hold-only, do not transmit 

(S) specifies Transmit and Save 

(D) specified discard without transmitting 

Note: Parentheses are part of the above elements. 

(pathname) see INPUT command 


This command specifies the disposition of output file(s) produced 
by the job. Unspecified files will be Hold-only by default. The 
OUTUSER, OUTPASS, and OUT commands must be specified before INPUT 
command to be effective. These commands will affect any following 
jobs submitted by this USER over this RJE-TELNET connection. A 
particular job may override these commands by NET control cards on 
the front of the input file. 


Once output disposition is specified by this OUT command or by a 
NET OUT card, the information is kept with the job until final 
output disposition, and is modifiable by the CHANGE command. 


OUTPUT RE-ROUTE 
CHANGE (Jjob-id) (out-file) = (disp) (pathname) 


This command changes the output disposition supplied with the job 
submission. The (job-id) is assumed recognizable by the RJE- 
server, who may verify if this USER is authorized to modify the 
specified job. After the job is identified, the other information 
has the same syntax and semantics as the original OUT command. 
CHANGE command may be specified for a job-file-id which was not 
mentioned at submission time and has the same effect as an 
original OUT command. 
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OUTPUT CONTROLS DURING TRANSMISSION 
(command) (count) (what) 


(command) ::= RESTART / RECOVER / BACK / SKIP / ABORT / HOLD 
these commands specify 
Restart the transmission (new RFC, etc.) 
Recover restarts transmission from last 
FTP Restart-marker-reply (see FTP). 
Back up the output "count" blocks 
Skip the output forward "count" blocks 
Abort the output, discarding it 
Hold the output after Aborting it 


(count)::= (empty) / (decimal-integer) 
(empty) implies 1 where defined 
(what) ::= @(pathname) / (job-id) (job-file-id) 
(pathname) is as in the INP command 
(job-id)::= (server recognized job identifier which was 
supplied at INP completion by the server) 
(job-file-id)::= (server recognized file identifier or 


if missing then the prime printer output 
of the specified job) 


This collection of commands will modify the transmission of output 
in progress or recently aborted. If output transmission is cut- 
off before completion, then the RJE-server will either try to 
resend the entire file if the file’s (disp) was Transmit-and- 
discard or will Hold the file for further User control if the 
(disp) was (S) transmit-and Save. Either during transmission, 
during the Save part of a transmit-and-Save, or for a Hold-only 
file; the above commands may be used to control the transmission. 
The @(pathname) form of (what) is permitted only if transmission 
is actually in progress. 


If the file’s state is inconsistent with the command then the 
command is illegal and ignored with reply. 


STATUS 


STATUS 
STATUS (job-id) 


These commands request the status of either the RJE-server ora 


particular job respectively. The information content of the 
Status reply is site dependent. 
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CANCEL/ALTER 


CANCEL (job-id) 
ALTER (job-id) (site dependent options) 


These commands change the course of a submitted job. CANCEL 
specifies that the job is to be immediately terminated and any 
output discarded. ALTER provides for system dependent options 
such as changing job priority, process limits, Terminate without 
Cancel, etc. 


OP 
OP (any string) 


The specified string is to be displayed to the Server site 
operator when any following job is initiated servicing from the 
batch queue of the Server. This command usually appears in the 
input file as a NET OP control card, but may be a TELNET command. 
It is cancelled as a all-jobs command by an OP "crlf" command (no 
text supplied). 


RJE CONTROL CARDS IN THE INPUT FILE 


Certain RJE commands may be specified by control cards in the front 
of the input file. If these controls appear, they take precedence 
over the same command given thru the RJE-TELNET connection and affect 
only this specific job. 


All these RJE control cards must appear as the first records of the 
job’s input-file. They all contain the control word NET in columns 
1-2. Scanning for these controls stop when the first card without 
NET in col 1-3 is encountered. 


The control commands appear in individual records and are terminated 
by the end-of-record (usually an 80 column card-image). Continuation 
is permitted onto the next record by the appearance of NET+ in 
columns 1-4 of the next record. Column 5 of the next record 
immediately follows the last character of the previous record. 


NET OUTUSER = (userid) 
NET OUTPASS = (password) 
NET OUT (out-file) = (disp) (pathname) 


NET OP (any string) 
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See the corresponding TELNET commands for details. One option 
permitted by the NET OUTUSER and NET OUT controls not possible from 
the TELNET connection is specification of different OUTUSERs for 
different OUTs, since the TELNET stores and supplies only an initial 
OUTUSER, but the controls may change OUTUSERs before each OUT control 
is encountered. 


RJE USE OF FILE TRANSFER PROTOCOL 


Most non-TIP files will be transferred to or from the RJE-server 
through the FTP process. RJE-server will call upon its local FTP- 
user supplying the Host, File-pathname, User-id, Password, and Mode 
of the desired transfer. FTP-user will then connect to its FTP- 
server counterpart in the specified host and set up a transfer path. 
Data will then flow through the RJE-FTP interface in the Server, over 
the Network, from/to the foreign FTP-server and then from/to the 
specified File-pathname in the foreign host’s file storage space. On 
output files, the file-pathname may be recognized by the foreign host 
as directions to a printer or the file may simply be stored; a User- 
RJE-process can supply output (pathname) by default which is 
recognized by its own Server-FTP as routing to a printer. 


Although many specifics of the RJE-Server/User-FTP interface are 
going to be site dependent, there are several FTP options which will 
be used in a standard way by RJE-Servers: 


T A new FTP connection will be initiated for each file to be 
transferred. The connection will be opened with the RJE User 
supplied User-id (OUTUSER or INUSER) and Password. 

2. The data bytesize will be 8 bits. 

3% The FTP Type, Structure, and Mode parameters are determined by 


the RJE transfer direction (I/O), the (transmission and (code) 
options supplied by the User: 
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I/O (TRANS) (CODE) FTP TYPE STRUCTURE MODE 
r* N = Ascii R Hasp 
I N E Image R Hasp 
I T = Ascii F Ascii 
I A = Ascii R Hasp 
T A E Image R Hasp 
O* A = Ascii-print R Hasp 
O A E Ebcdic-print R Hasp 
e) N - Ascii R Hasp 
O N E Image R Hasp 
O T = Ascii-print F Ascii 
Note: The I* and O* are the default cases. 
4. The service commands used will be Retrieve for input and Append 


(with create) for output. The FTP pathname will be the (file- 
name) supplied by the RJE User. 


Ds On output in Hasp form, the User-FTP at the RJE-Server site will 
send Restart-markers at periodic intervals (like every 100 
lines, or so), and will remember the latest Restart-—marker-reply 
with the file. If the file transfer is not completed and the 
(disp) is (S) then the file will be held pending User 
intervention. The User may then use the RECOVER command to 
cause a FTP restart at the last remembered Restart-marker-reply. 


6. The FTP Abort command will be used for the RJE ABORT and CANCEL 
commands. 


The specific form of the FTP commands used by an RJE-Server site, and 
the order in which they are used will not be specified in this 
protocol. 


Errors encountered by FIP fall into three categories: a)access errors 
or no storage space error; b)command format errors; and c)transfer 
failure errors. Since the commands are created by the RJE-Server 
process, an error is a programming problem and should be logged for 
attention and the situation handled as safely as possible. 
Transmission failure or access failure on input cause an effective 
ABORT and user notification. Transmission failure on output causes 
RESTART or Save depending on (disp). (see OUT command.) Access 
failure on output is a problem since the User may not be accessible. 
A status response should be queued for that user, should he happen to 
inquire; a (disp)=(S) file should be Held; and a (disp)= (empty) 
transmit-—and-discard file should be temporarily held and then 
discarded after a reasonable time if not claimed. 
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REPLIES OVER THE TELNET CONNECTION 


Each action of the RJE-server, including entry of each TELNET 
command, is noted over the TELNET connection to the User. These 
RJE-server replies are formatted for Human or Process interpretation. 
They consist of a leading 3-digit numeric code followed by a blank 
followed by a text explanation of the message. The numeric codes are 
assigned by groups for future expansion to hopefully cover other 
protocols besides RJE (like FTP). The numeric code is designed for 
ease of interpretation by processes. The three digits of the code 
are interpreted as follows: 


a) The first digit specifies the "type" of response indicated: 


000 These "replies" are purely informative, and are issued 
voluntarily by the Server to inform a User of some state of 
the server’s system. 


100 Replies to a specific status inquiry. These replies server as 
both information and as acknowledgement of the status request. 


200 Positive acknowledgement of some previous command/request. 
The reply 200 is a generalized "ok" for commands which require 
no other comment. Other 2xx replies are specified for 
specific successful actions. 


300 Incomplete information supplied so far. No major problem, but 
activity can not proceed with the input supplied. 


400 Unsuccessful reply. A request was correctly specified, but 
could not be correctly completed. Further attempts will 
require User commands. 

500 Incorrect or illegal command. The command or its 
parameters were invalid or incomplete from a syntactic view, 
or the command is inconsistent with a previous command. The 
command in question has been totally ignored. 


600-900 Reserved for expansion. 


b) The second digit specifies the general subject to which the 
response refers: 


x00-x29 General purpose replies, not assignable to other subjects. 


x30 Primary access. There replies refer to the attempt to "log- 
on" to a Server service (RJE, FTP, etc.). 
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x40 


x50 


x60 


x70- 


c) The 
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Secondary access. The primary Server is commenting on its 
ability to access a secondary service (RJE must log-on to a 
remote FTP service). 

FTP results. 

RJE results. 


x99 Reserved for expansion. 


final digit specifies a particular message type. Since the 


code is designed for an automation process to interpret, it is not 
necessary for every variation of a reply to have a unique number, 
only that the basic meaning have a unique number. The text of a 
reply can explain the specific reason for the reply to a human 
User. 


Each TELNET line (ended by "crlf") from the Server is intended to be 
a complete reply message. If it is necessary to continue the text of 
a reply onto following lines, then those continuation replies contain 
the special reply code of three blanks. 


The assigned reply codes relating to RJE are: 


000 
030 
050 
060 
100 
150 
151 
160 
161 
200 
201 
202 
203 
230 
231 
232 
240 
250 
251 


252 
253 


Holland 


General information message (time of day, etc.) 
Server availability information 
FTP commentary or user information 
RJE or Batch system commentary or information 
System status reply 
File status reply 
Directory listing reply 
RJE system general status reply 
RJE job status reply 
Last command received ok 
An ABORT has terminated activity, as requested 
ABORT request ignored, no activity in progress 
The requested Transmission Control has taken effect 
LOG-on completed 
Log-off completed, goodbye. 
Log-off noted, will complete when transfer done 
File transfer has started 
FTP file transfer started ok 
FTP Restart-marker-reply 

Text is: MARK yyyy = mmmm 

where yyyy is data stream marker value (yours) 

and mmmm is receiver’s equivalent mark (mine) 

FTP transfer completed ok 
Rename completed 
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254 Delete completed 
260 Job (job-id) accepted for processing 
261 Job (job-id) completed, awaiting output transfer 
262 Job (job-id) Cancelled as requested 
263 Job (job-id) Altered as requested to state (status) 
300 Connection greeting message, awaiting input 
301 Current command not completed 

(may be sent after suitable delay, if no "crlf") 
330 Enter password 

(may be sent with hide-your-input mode) 
360 INPUT has never specified an INPATH 
400 This service is not implemented 
401 This service is not accepting log-on now, goodbye. 
430 Log-on time or tries exceeded, goodbye. 
431 Log-on unsuccessful, user and/or password invalid 
432 User not valid for this service 
434 Log-out forced by operator action, please phone site 
435 Log-out forced by system problem 
436 Service shutting down, goodbye. 
440 RJE could not log-on to remote FTP for input transfer 
441 RJE could not access the specified input file through FTP 
442 RJE could not establish (host-socket) input connection 
443 RJE could not log-on to remote FTP for output delivery 
444 RJE could not access file space given for output 
445 RJE could not establish (host-socket) output connection 
450 FTP: The named file does not exist (or access denied) 
451 FTP: The named file space not accessible by YOU 
452 FTP: Transfer not completed, data connection closed 
453 FTP: Transfer not completed, insufficient storage space 
460 Job input not completed, ABORT performed 
461 Job format not acceptable for processing, Cancelled 
462 Job previously accepted has mysteriously been lost 
463 Job previously accepted did not complete 
464 Job-id referenced by STATUS, CANCEL, ALTER, CHANGE, or 
Transmission Control is not known (or access denied) 
465 Requested Alteration not permitted for the specified job 
466 Un-deliverable, un-claimed output for (job-id) discarded 
500 Last command line completely unrecognized 
501 Syntax of the last command is incorrect 
502 Last command incomplete, parameters missing 
503 Last command invalid, illegal parameter combination 
504 Last command invalid, action not possible at this time 
505 Last command conflicts illegally with previous command(s) 
506 Requested action not implemented by this Server 
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SEQUENCING OF COMMANDS AND REPLIES 


The communication between the User and Server is intended to be an 
alternating dialogue. As such, the User issues an RJE command and 
the Server responds with a prompt primary reply. The User should 
wait for this initial success or failure response before sending 
further commands. 


A second type of reply is sent by Server asynchronously with respect 
to User commands. These replies report on the progress of a job 
submission caused by the INPUT command and as such are secondary 
replies to that command 


The final class of Server "replies" are strictly informational and 
may arrive at any time. These "replies" are listed below as 


spontaneous. 


COMMAND-REPLY CORRESPONDENCE TABLE 


COMMAND Success Fail 
USER 230,330 430,431, 432,500-505 
PASS 230 430,431, 432,500-505 
BYE 231,232 500-505 
INID 200 500-505 
INPASS 200 500-505 
INPATH 200 500-505 
INPUT 240 360, 440-442, 500-505 
sec. Input retrieval 260 460,461 
sec. Job execution 261 462,463 
sec. Output Transmission -- 443,444,445, 446 
ABORT (input) 201,202 500-505 
OUTUSER 200 500-505 
OUTPASS 200 500-505 
OUT 200 500-505 
CHANGE 200 500-505 
RESTART /RECOVER/BACK/ 
SKIP/ABORT (output) /HOLD 203 464, 500-506 
STATUS 1xx 464,500-505 
CANCEL 262 464,500-506 
ALTER 263 464, 465,500-506 
OP 200 500-505 
Spontaneous Oxx, 300,301 434-436 


Note: For commands appearing on cards, the 200 is not sent 
but the 500-505 errors may be "asynchronously" sent. 
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TYPICAL RJE SCENARIOS 


1. TIP USER WANTING HOT CARD READER TO HOSTX 

a) TIP user opens TELNET connection to HOSTX socket 5 

b) Commands sent over TELNET to RJE 
USER=myself 
PASS=dorwssap 
OUT=PORT 7 
INPUT=PORT 5 

c) RJE-server connects to the User’s host port 5 and begins 
reading. When end-of-job card is recognized, the job is queued 
to run. The connection to the card reader is still open for 
more input as another job 

d) The first job finishes. A connection to the Users host port 7 
is established by RJE-server and the output is sent as an NVT 
stream. 

e) Continue at any time with another deck at step c). 


2. TIP WITH JOB-AT-A-TIME CARD READER 
a) thru d) the same but User closes Reader after the deck 
e) The output finishes and the printer connection closes. 
f) INPUT may be typed any time after step c) finishes and another 
job will be entered starting at c). 


3. HOSTA USER RUNS JOB AT HOSTC, INPUT FROM HOSTB 

a) User TELNET connects to HOSTC socket 5 for RJE 
USER=roundabout 
PASS=aaabbbc 
OUTUSER=roundabl 
OUT=:E/.sysprinter 
OUT puncher = (s)HOSTB:NE/my.savepunch 
INUSER=rounder 
INPASS=x.X.X 
INPUT=HOSTB:E/my.jobinput 

b) The RJE-server has FTP retrieve the input from HOSTB using 
Userid of "rounder" and Password of "x.x.x" for file named 
"my.jobinput". 


c) The job finishes. RJE-server uses FTP to send two files: the 
print output is sent to HOSTA in EBCDIC with ASA carriage 
control to file ".sysprinter" while the file known as "puncher" 


is sent to HOSTB in EBCDIC without carriage-control to file 
"my.savepunch". 

d) when the outputs finish, RJE-server at HOSTC discards the print 
file but retains the "puncher" file. 

e) The User who had signed out after job submission has gotten his 
output and checked his file "my.savepunch" at HOSTB. He 
deletes the saved copy at HOSTC by re-calling RJE at HOSTC. 
USER=roundabout 
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PASS=aaabbbcc 
ABORT job123 puncher 
or by 
CHANGE job123 puncher = (D) 
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